Neutral build

In software development, a neutral build is a build that reflects the current state of the source code checked into the source code version control system by the developers and done in a neutral environment, that is in an environment not used for development.

A nightly build is a neutral build that takes place automatically. These typically take place when no one is likely to be working in the office so that there are no changes to the source code during the build. The results of the build are inspected by the arriving programmers, who generally place a priority on ensuring the recent changes to the source code have not broken the build process or functionality of the software.

When someone says a developer "broke the build", they are effectively saying that a developer checked in code which might very well have compiled (and hopefully also run properly) in their account, but does not compile (and therefore, cannot be run) in anyone else's account. This is typically due to additional developer-specific changes that were either not checked in, or (in the case of environment variables, etc.) were modifications to systems not under revision control. One of the most common cases is remembering to check in all modified files, but forgetting to add newly created files to the repository. If the other developers check out the new code without being aware of the problem, their work may grind to a halt while they wait for the problem to be fixed (or try to fix it themselves, which can be even more problematic, if multiple developers attempt to fix the issue at the same time). This naturally can result in a significant loss of productivity.

Neutral builds are important for software development processes running at high loads with short schedules (see extreme programming, startup); not having them means that any build that needs to be created for the software quality assurance department has to be created using code which may be in the middle of major modifications, and which would best be left out of a build for testing (particularly a build being evaluated for possible release).

Neutral builds can be done on a machine which is also used for active development if enough caution is taken, but it is safer to dedicate a machine to that purpose because an issue in the build process could cause the machine to become unstable.

Hazards

Some noteworthy obstacles to a reliable neutral build process are:

• Getting a consistent set of makefiles and other project control files. This step tends to expose consistency problems between various development machines, particularly with respect to directory structures, compiler and linker options, and environment variables.
• Having the same operating system and tools setup as the development machines. Again, this step tends to expose differences between the machines in use by different developers.
• Having an automated checkout procedure that completely cleans out the target directory first, and gets all files required. Ideally, however, the system doesn't waste time with large files that aren't required.
• Integrating with the version control system, particularly if encryption, authentication, or both are being used (see SSH). This must be done with care, as it is typically very easy to make it "work" without being secure, and the temptation or pressure to just "fix it later" may be strong.
• Ensuring all materials come from the correct directory. It is strongly recommended that there be only one copy of the source tree on the neutral build machine.
• Problems with version numbering.
• Decoupling the build process from specific IDEs. This is tough to convince some people to do, but in the end, it leads to cleaner build processes. Trouble usually arises in areas such as EJBs (especially with IBM's WebSphere product which requires the use of one of their IDEs to generate some binary files).
• Getting adequate feedback from the build system so that you can tell what is broken when something breaks. The worst kind of feedback is simply a lack of linked binary files; the best identifies not only compilation failures, but linker failures, missing source materials, missing include directories, and so on.
• Understanding the difference between branching and releasing. Releasing software requires a branch whose state can be returned to. A release is usually a tag on a branch or mainline like the HEAD. A branch can be used for parallel development or for patch releases to a release. A branch is not necessarily a release.
• Ensuring developer environments are easy to set up and get into a useful state. The varied state of machines and software installations can make this task quite daunting.
• Convincing management of the benefit of automated builds.